The IEEE (Institute of Electrical and Electronics Engineers) 802.16 Working Group is developing the 802.16m air interface specification to meet the requirements of IMT (International Mobile Telecommunications)—Advanced next generation mobile systems. Based on the IEEE 802.16m draft standard (e.g., see Non-Patent Literature 1), the WiMAX (Worldwide Interoperability for Microwave Access) Forum is working out the WiMAX Release 2.0 MSP (Mobile System Profile) and PICS (Protocol Implementation Conformance Statement). The IEEE 802.16m standard and the WiMAX Release 2.0 MSP and PICS are expected to be finalized in early 2011.
The IEEE 802.16 Working Group has also started envisioning the future 802.16/WiMAX networks beyond 802.16m/WiMAX 2.0. There is a common understanding among 802.16/WiMAX community that future 802.16/WiMAX networks should support explosive mobile data traffic growth driven by large screen devices, multimedia applications as well as more connected users and devices. Future 802.16/WiMAX networks should also interwork efficiently with other radio technologies, e.g., 802.11/Wi-Fi (Wireless Fidelity).
Future 802.16/WiMAX networks should be enhanced significantly compared with 802.16m network in terms of various performance metrics such as throughput and SE (Spectral Efficiency). For example, in urban-coverage scenario, future 802.16/WiMAX networks target at the cell-edge SE of two times of 802.16m/WiMAX 2.0 network in both UL (Uplink) and DL (Downlink) (e.g., see Non-Patent Literature 2). Note that 802.16m/WiMAX 2.0 network has at least a DL cell-edge SE of 0.06 bps/Hz/sec with 4×2 antenna configuration and an UL cell-edge SE of 0.03 bps/Hz/sec with 2×4 antenna configuration.
CO-Operative techniques, e.g., CliCo (Client Collaboration), have promised significant improvements in the cell-edge SE and total network energy efficiency of a wireless communication system. CliCo is a technique where clients interact to jointly transmit/receive data in wireless environments (e.g., see Non-Patent Literature 3). In CliCo, client clustering and peer-to-peer communication are exploited to transmit/receive information over multiple paths between BS and client. As a result, the cell-edge SE can be improved without increase in infrastructure cost. Furthermore, the battery of clients with poor channels can be extended.
A diagram illustrating an exemplary wireless communication system 100 with CliCo is shown in FIG. 1. Wireless communication system 100 is configured of BS (Base Station) 102 and a plurality of MSs (Mobile Stations) such as MS 104 and MS 106.
A block, diagram illustrating exemplary BS 102 is shown in FIG. 2. BS 102 is equipped with WiMAX communication function only, which is configured of WiMAX PHY block 130 and WiMAX MAC block 120. WiMAX MAC block 120 implements WiMAX OFDMA (Orthogonal Frequency Division Multiple Access)-based media access control protocols. WiMAX PHY block 130 implements the WiMAX OFDMA-based physical layer protocols under the control of WiMAX MAC block 120.
With reference to FIG. 2, WiMAX MAC block 120 further is configured of control section 122, scheduler 124, message generation section 126, and message processing section 128. Control section 122 controls general MAC protocol operations. Scheduler 124 schedules the allocation of resources to the MSs under the control of control section 122. Message generation section 126 receives resource allocation scheduling information from scheduler 124 and then generates data packets and DL control information. Message processing section 128 analyzes data packets and UL control information received from the plurality of MSs under the control of control section 122 and reports its analysis result to control section 122.
Note that data packets and DL control information generated by message generation section 126 are transmitted by BS 102 to the plurality of MSs via an OFDMA transmitter (not shown in FIG. 2) inside WiMAX PHY block 130. Data packets and UL control information analyzed by message processing section 128 are received by BS 102 via an OFDMA receiver (not shown in FIG. 2) inside WiMAX PITY block 130.
With reference to FIG. 2, there are HFBCH (HARQ Feedback Channel) generation section 132 and resource allocation generation section 134 inside message generation section 126, where HARQ stands for Hybrid Automatic Repeat Request.
HFBCH generation section 132 generates HARQ feedback channels for UL data transmission, which carry HARQ feedback information (e.g., ACK/NACK) for UL data transmission. Resource allocation generation section 134 generates resource allocation control information for DL/UL data transmission, which carries resource allocation information for each of the plurality of MSs.
In terms of GRA (Group Resource Allocation), resource allocation control information generated by resource allocation generation section 134 may contain group configuration information as well as group resource allocation information including indexing information of HFBCH for DL/UL GRA transmission. The HFBCHs generated by HFBCH generation section 132 may contain HARQ feedback information for UL GRA transmission.
With reference to FIG. 2, there exists HFBCH analyzing section 136 inside message processing section 128. HFBCH analyzing section 136 analyzes the received HFBCHs for DL data transmission and determines whether the corresponding DL data transmission is successful or not. In terms of GRA, HFBCH analyzing section 136 may derive HARQ feedback information for DL GRA transmission from the received UL control information.
A block diagram illustrating exemplary MS 104 is shown in FIG. 3. MS 104 is equipped with both WiMAX and Wi-Fi communication functions, which is configured of WiMAX PHY block 142, Wi-Fi PHY block 144, WiMAX MAC block 146, Wi-Fi MAC block 148, and GLL (Generic Link Layer) block 150. WiMAX MAC block 146 implements WIMAX OFDMA-based MAC (media access control) protocols. WiMAX PHY block 142 implements the WiMAX OFDMA-based physical layer protocols, under the control of WiMAX MAC block 146. Wi-Fi MAC block 148 implements Wi-Fi CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance)-based MAC (media access control) protocols. Wi-Fi PHY block 144 implements the Wi-Fi OFDM (Orthogonal Frequency Division Multiplexing)/DSSS (Direct Sequence Spread Spectrum)-based physical layer protocols, under the control of Wi-Fi MAC block 148. GLL block 150 functions as managing interworking between heterogeneous WiMAX and Wi-Fi links.
With reference to FIG. 3, WiMAX MAC block 146 further is configured of control section 154, message generation section 152, and message processing section 156. Control section 154 controls general MAC protocol operations. Message generation section 152 generates UL control information and data packets under the control of control section 154. Message processing section 156 analyzes data packets and DL control information received from BS 102 under the control of control section 154, and provides its analysis result to control section 154.
Note that data packets and UL control information to generated by message generation section 152 are transmitted from MS 104 to BS 102 via an OFDMA transmitter (not shown in FIG. 3) inside WiMAX PHY block 142. Data packets and DL control information analyzed by message processing section 156 are received by MS 104 via an OFDMA receiver (not shown in FIG. 3) inside WiMAX PHY block 142.
With reference to FIG. 3, there are resource analyzing section 151 and HFBCH analyzing section 153 inside message processing section 156. HFBCH analyzing section 153 analyzes the received HFBCHs for UL data transmission and determines whether the corresponding UL data transmission is successful or not. Resource analyzing section 151 analyzes the received resource allocation control information and derives the resource allocation information specific to MS 104. In ease of UL data transmission, data packet generated by message generation section 152 under the control of control section 154 will then be transmitted by MS 104 to BS 102 according to the derived resource allocation information. In case of DL data transmission, data packet transmitted by BS 102 to MS 104 will then be received by MS 104 according to the derived resource allocation information.
In terms of GRA, resource analyzing section 151 inside message processing section 156 may derive group configuration information as well as group resource allocation information including indexing information of HFBCH for DL/UL GRA transmission from received resource allocation control information. HFBCH analyzing section 153 may derive HARQ feedback information for UL GRA transmission from the received. HFBCHs.
With reference to FIG. 3, there exists HFBCH generation section 155 inside message generation section 152, HFBCH generation section 155 generates HARQ feedback channels, which include HARQ feedback information, for DL data transmission. In terms of GRA, HFBCH generation section 155 may generate HARQ feedback channels for DL GRA transmission.
A block diagram illustrating exemplary MS 106 is shown in FIG. 4. MS 106 is also equipped with both WiMAX and Wi-Fi communication functions, which has a very similar structure and functionality as MS 104. A main difference between MS 104 and MS 106 is that unlike MS 106, there is scheduler 158 inside Wi-Fi MAC block 148 of MS 104 as shown in FIG. 3, which is used for cooperation scheduling for CliCo.
With reference to FIG. 1, BS 102 communicates with MS 104 via WiMAX links 108a and 108b, and communicates with MS 106 via WiMAX links 110a and 110b. MS 104 communicates with MS 106 via peer-to-peer Wi-Fi links 112a and 112b. Alternatively, MS 104 may communicate with MS 106 via other radio technologies if available, such as WiMAX, Bluetooth, or 60 GHz mmW (Millimeter Wave).
Note that CliCo can be implemented in both DL and UL of wireless communication system 100. As an example, the operation of UL CliCo in wireless communication system 100 is described below.
With reference to FIG. 1, when the signal quality of WiMAX link 108a between BS 102 and MS 104 becomes poor, MS 104 may start the UL CliCo procedure such as neighbor discovery and cooperator selection/allocation. If the signal quality of WiMAX link 110a between BS 102 and MS 106 is good. MS 104 may select MS 106 as its cooperator. In the context of CliCo, MS 104 is called originating MS, and MS 106 is called cooperating MS.
CliCo may happen in various scenarios. For example, originating MS 104 may be deep inside a cafeteria and thus the signal quality of WiMAX links for originating MS 104 may be very poor. However, cooperating MS 106 may be much closer to window or entrance of the cafeteria than originating MS 104, and thus cooperating MS 106 may have a much better signal quality of WiMAX links than originating MS 104.
A diagram illustrating an exemplary frame structure 200 is shown in FIG. 5, which can be applied to wireless communication system 100 with CliCo as shown in FIG. 1. With reference to FIG. 5, each of frame 202 and frame 212 is configured of eight subframes. Five of them are DL subframes, and the others are UL subframes.
So far as UL CliCo is concerned, during first DL subframe 204 of frame 202, BS 102 may transmit MAP 220 indicating control information to a plurality of MSs connected to BS 102, including originating MS 104 and cooperating MS 106 engaged in CliCo, MAP 220 is configured of a plurality of MAP IEs (Information Elements). Some of MAP IEs may carry HARQ feedback information for UL data transmission; and some of MAP IEs may carry resource allocation information for DL/UL data transmission. One MAP IE in MAP 220 carrying HARQ feedback information forms one HBFCH for UL data transmission.
During time period 208 between first DL subframe 204 and first UL subframe 206 of frame 202, originating MS 104 and cooperating MS 106, respectively, need to decode MAP 220 to obtain their resource allocation information including HFBCH indexing information. Also originating MS 104 needs to transmit UL data burst 250 to cooperating MS 106 via peer-to-peer Wi-Fi link 112a. 
During first UL subframe 206 of frame 202, if originating MS 104 successfully decodes MAP 220 sent by BS 102 via WiMAX link 108b, it will transmit UL data burst 250 to BS 102 via WiMAX link 108a according to its received resource allocation information. On the other hand, if cooperating MS 106 successfully decodes MAP 220 sent by BS 102 via WiMAX link 110b and successfully receives UL data burst 250 sent by originating MS 104 via peer-to-peer Wi-Fi link 112a, cooperating MS 106 will simultaneously transmit the same UL data burst 250 to BS 102 via WiMAX link 110a according to its received resource allocation information. Consequently BS 102 can combine two copies of UL data burst 250 received from WiMAX link 108a and WiMAX link 110a to improve the quality of received signal.
During second DL subframe 214 of frame 212, BS 102 to may transmit MAP 240 to the plurality of MSs connected to BS 102, including originating MS 104 and cooperating MS 106 engaged in CliCo. As mentioned above, some of HFBCHs in MAP 240 may carry HARQ feedback information for UL data burst 250 transmitted by originating MS 104 and cooperating MS 106 during first UL subframe 206 of frame 202.
During time period 218 between second DL subframe 214 and first UL subframe 216 of frame 212, originating MS 104 and cooperating MS 106, respectively, need to decode the corresponding HFBCHs in MAP 240 to obtain their HARQ feedback information for UL data burst 250 according to their HFBCH indexing information which are obtained by decoding MAP 220 during time period 208.
During first UL subframe 216 of frame 212, if the HARQ feedback information implies that BS 102 does not successfully decode UL data burst 250 transmitted by originating MS 104 and cooperating MS 106 during first UL subframe 206 of frame 202, originating MS 104 and cooperating MS 106 may need to retransmit UL data burst 250.
As mentioned above, future 802.16/WiMAX networks should support explosive mobile data traffic. Furthermore, future 802.16/WiMAX networks should provide enhanced quality of experience for mobile internet applications, such as VoIP (Voice over Internet Protocol). Considering VoIP has a periodic traffic pattern and with relatively fixed payload size, various PHY/MAC mechanisms have been designed especially to improve quality of experience for VoIP such as PA (Persistent Allocation) and GRA. In the present invention, the application of GRA to CliCo is addressed.
GRA mechanism specified in the IEEE 802.16m draft standard (e.g., sec Non-Patent Literature 1) does not deal with CliCo. However, GRA mechanism can be applied to CliCo in a straightforward manner.
According to the IEEE 802.16m draft standard (e.g., see Non-Patent Literature 1). GRA mechanism allocates resources to multiple users as a group in order to save control overhead. This resource allocation is performed per transport flow. With reference to FIG. 1, the method of applying GRA to CliCo is configured of two operations: That is, i) BS 102 adds flows of originating MS 104 and cooperating MS 106 into a group or deletes flows of originating MS 104 and cooperating MS 106 from a group.
ii) BS 102 allocates resources to the flows of originating MS 104 and cooperating MS 106 within the same group.
According to the IEEE 802.16m draft standard (e.g., see non-Patent Literature 1), when adding a flow of originating MS 104 (or cooper g MS 106) into a group, BS 102 transmits group configuration information in a unicast MAC control message to originating MS 104 (or cooperating MS 106). When allocating resources to the flows of originating MS 104 and/or cooperating MS 106 within the group, BS 102 transmits group resource allocation information including HFBCH indexing information in a multicast MAP IE to originating MS 104 and cooperating MS 106. Note that group configuration information transmitted in the unicast MAC control message and group resource allocation information transmitted in the multicast MAP IE are generated by message generation section 126 as shown in FIG. 2.
According to the IEEE 802.16m draft standard (e.g., see Non-Patent Literature 1), the group configuration information transmitted in the unicast MAC control message can be used to interpret the group resource allocation information transmitted in the corresponding multicast MAP IE. The content of the group configuration information includes:                Flow identifier;        User bitmap size;        UBI (User Bitmap Index);        Group identifier;        Allocation periodicity; and        MIMO (Multiple Input Multiple Output) mode set or the like        
The flow identifier is used to inform an MS which of its flows is added into a group, which has a size of 4 bits. The user bitmap size indicates the number of bits used for user bitmap transmitted in the multicast MAP IE. The user bitmap size may be one of 4 bits, 8 bits, 16 bits, and 32 bits. The UBI indicates the index of the flow of MS in the user bitmap, which has a size of 5 bits. The group identifier uniquely identifies the DL/UL group to which the flow of MS is added, which has a size of 12 bits. The allocation periodicity specifics how often the multicast MAP IE carrying the corresponding group resource allocation information is transmitted, which may be one of 1 frame, 2 frames, 4 frames, and 8 frames. The MIMO mode set signals MIMO modes supported in the group.
A main difference between the group configuration information for originating MS 104 and cooperating MS 106 is that the UBIs of originating MS 104 and cooperating MS 106 are different. Furthermore, since the group configuration information is unicast to originating MS 104 and cooperating MS 106, respectively, cooperating MS 106 does not know the UBI of originating MS 104; vice versa.
According to the IEEE 802.16m draft standard (e.g., see Non-Patent Literature 1), the group configuration information may further include a set of four HARQ burst sizes. For example, the set of four HARQ burst sizes may be {6 bytes, 8 bytes, 9 bytes, 10 bytes}. Note that the burst size is the size of encoded packet which a may be partitioned into a plurality of FEC (Forward Error Correction) blocks. The burst size may include the addition of CRC (Cyclic Redundancy Code) per burst and/or per FEC block when applicable.
Corresponding to each of four HARQ burst sizes, the group configuration information may also include a set of eight resource sizes. For example, for the HARQ burst size of 9 bytes, the set of eight resource sizes may be {1 LRU, 2 LRUs, 3 LRUs, 4 LRUs, 5 LRUs, 6 LRUs, 7 LRUs, 8 LRUs} where LRU stands for Logical Resource Unit. For each of other three HARQ burst sizes of 6 bytes, 8 bytes and 10 bytes, the set of eight resource sizes may be different or the same as the HARQ burst size of 9 bytes.
According to the IEEE 802.16m draft standard (e.g., see Non-Patent Literature 1), a portion of the group resource allocation information is carried by bitmaps transmitted in the multicast MAP IE. A diagram illustrating exemplary bitmaps carrying partial group resource allocation information according to the IEEE 802.16m draft standard (Non-Patent Literature 1) is shown in FIG. 6. There are two bitmaps used to carry partial group resource allocation information. One is user bitmap 302, and the other is resource allocation bitmap 304.
According to the IEEE 802.16m draft standard (e.g., see Non-Patent Literature 1), user bitmap 302 uses 1 bit per flow to signal which flows are scheduled in the current frame. With reference to FIG. 6, the UBI of originating MS 104 is “00000”, and therefore the first bit of user bitmap 302 is referenced. The UBI of cooperating MS 106 is “00011” and so the fourth hit of user bitmap 302 is referenced. So the flows (corresponding to data) of both originating MS 104 and cooperating MS 106 are specified by resource allocation map 304 and transmitted to the current frame.
With reference to FIG. 6, resource allocation bitmap 304 is configured of a plurality of 5-bit resource allocation indications, each of which is for a specific scheduled flow. In each of 5-bit resource allocation indications, the first 2 hits is used to signal HARQ burst size and the last 3 bits is used to signal resource size.
With reference to FIG. 6, the HARQ burst sizes are selected from among four burst sizes {6 bytes, 8 bytes, 9 bytes, 10 bytes} and indicated by “00,” “01,” “10” and “11.”
In FIG. 6, both originating MS 104 and cooperating MS 106 are indicated by “10” and therefore both HARQ burst sizes are 9 bytes.
The resource sizes of originating MS 104 and cooperating MS 106 are indicated by “111” and “001”, respectively. So the resource sizes of originating MS 104 and cooperating MS 106 may be 8 LRUs and 2 LRUs, respectively.
According to the IEEE 802.16m draft standard (e.g., see Non-Patent Literature 1), in addition to user bitmap 302 and resource allocation bitmap 304, another bitmap called MIMO bitmap may be used if multiple MIMO modes are supported in a group.
A table illustrating an exemplary GRA MAP IE for transmitting the group resource allocation information according to the IEEE 802.16m draft standard (e.g., see Non-Patent Literature 1) is shown in Table 1.
TABLE 1SizeSyntax(bit)Description/NotesGRA_MAP_IE( ){MAP IE type4GRA MAP IEUser bitmapVariableIndicate scheduled MSs in agroup.The size of the bitmap is equalto the User Bitmap Size signaledto each MS in the groupconfiguration information.Resources Offset7Indicate starting LRU forresource allocation to thisgroup.HFA offset6Indicate the start of the HFBCHindex used for scheduledallocations.ResourceVariableIndicate the HARQ burstAllocation Bitmapsize/resource size for each ofscheduled MSs.. . .}
In addition, according to the IEEE 802.16m draft standard (e.g., see Non-Patent Literature 1), the HFBCH index for a scheduled flow in a group is a predetermined function of its UBI and the HFA offset as shown in Table 1. In other words, each of originating MS 104 and cooperating MS 106 can compute its HFBCH index according to its UBI after decoding the GRA MAP IE as shown in Table 1.
A flowchart illustrating method 400 of receiving resource allocation information at originating MS 104 (or cooperating MS 106) according to the IEEE 802.16m draft standard (e.g., see Non-Patent Literature 1) is shown in FIG. 7. Method 400 starts at Step 402. At Step 404, originating MS 104 (or cooperating MS 106) cheeks the user bitmap according to its UBI. At Step 406, originating MS 104 (or cooperating MS 106) determines whether its flow is scheduled in the current frame. If the flow of originating MS 104 (or cooperating MS 106) is scheduled in the current frame, at Step 408, it proceeds to check the resource allocation bitmap to derive its HARQ burst size and resource size according to its UBI. After that at Step 410, originating MS 104 (or cooperating MS 106) computes its HFBCH index according to its UBI. At Step 406, if the flow of originating MS 104 (or cooperating MS 106) is not scheduled in the current frame, method 400 stops at Step 412.